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^ An integrated, processor is provided . virhereii 




in 



' a common semiconductor^ die 'arid ^are r linked By 
a common "local bus. A testing circuit, also 
^ rsituated^ort the^dfeuand^ coupled: 'io:4heucQn£ne&^ 






^rnron^ffnoporoenK- 



" " ~~testing7^ The 
host computer generates the Jest^command 
~"sighals"which are' sent tcT&nd" received" by" the 
testing circuit in the integrated processor. A 
debug memory space is reserved in the main 
system memory of the target computer for stor- 
- - - - - age- of . debug .:>scfty^reiLiiWh 



thus stored is executed when the processor bn " : " * * r 



■.^r^v-lhe target computer enters a debug'mod'e. 
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This invention relates in general to microprocessors and, more particularly, to a type of microprocessor 

™ — ~ a ^ a n,°[ntegrated microprocessor". An "integrated microprocessor" is a microprocessor in which an 

- -.^ is integrated „with other functionalunits on a common semicon- 
' ductordie/ ....„" " * " , ^..^ ^ . 

have- progressed-f rom early 

^J^P 1 ®™^^*' 0 ™"' through lateriS bit 32 bit and 64 bit implementations/At the same time that the data 

. 'Bandwidth of microprocessors has increased, the amount of functionality provided on a single semiconductor 

die has also substantially increased. For example, whereas the standalone Intel 386 microprocessor includes 

mainly a CPU and a'memory management unit (MMU), in comparison the standalone Intel 486 microprocessor 

IfeiiJi^i^ memory management unit (MMU) all located together 

r ¥lli-Qn -tfie,.s"g^ 

T^J^ functional units as the inter- 

'■■-':rupf controller, direct memory access (DMA) : cinitiftry and'nfiniory obhtrbf ler all' on the same semiconductor 
die together with the standalone microprocessor design layout. Microprocessors with such a very high degree 
« ^ ^t^f functio^ihtegratio^wiU be referred to as integrated processors" or "Integrated microprocessors". In other 

w°rc}s, "[^egrated processors" are th ose processors which include a standalone microprocessor layout and 

" one or more fun^ semiconductor die. 

Integrated pro^sors present increased challenges to the microprocessor designer in terms of functional 
testability. In the case of older microprocessors, functional units such as DMA, the interrupt controller, the FPU, 
and others were located on a separately packaged chip or discrete circuitry separate from the microprocessor. 
IrUhose cases, the functional unit was readily accessible for testing. However, when these functional units 
are integrated on a common semiconductor die in an "integrated processor", they are much less accessible to 
< those involved^; device and-system testing, - * - ™ - 

-—^ItwHI be-assumed that the integrated processor is intended for use as part of a larger functional structure 
such as a personal computer, workstation or other computing device. For convenience, the board on which 
the integrated processor is located will be called the motherboard, as is common practice. The processor is 
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^ngfsuelralpersonaPci 



In-cirtfttTenr 

J? t ^py.?^.^ e T"* n ^.'" :u .^' emu * ator » instead of plugging the processor into the processor socket on the moth 

Moreover, such "in-circuif emulators often only fit pre-production models of a personal computer and not the 
final production model. Another disadvantage of such "in-circuit" emulators is that they take so long to build 

^^^^ 

semiconductor 

feii'Access Port 

, - _3£SISSi^^ provided 

vaf^ 
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More particularly, a shift register stage is located adjacent each component pin of the device under test. 
In this manner, signals at component boundaries can be observed and controlled using scan testing techni- 
ques. A test vector is supplied to the boundary scan registers and the resultant output is compared with the 
expected output. Errors in the functioning of some of the components of the device may be determined in this 
manner. The protocol by which the tester communicates with the boundary scan registers is referred to as the 
JTAG (Joint Test Action Group) protocol. The IEEE 1149.1 standard defines a non-proprietary JTAG interface 
through which test signals using this testing protocol are transmitted. 
gcjs»3^J^^ whi,e boundary scan can be a helpful testing technique, it is a relatively slow technique 
" "which becomes eVeh slower as the testing complexity increases on larger and more complex microprocessor 
devices such as "integrated processors". Another disadvantage of boundary scan testing is that it often does 
not provide full test information on all components of a device under test. 

Testing or debugging of a microprocessor system, for example a personal computer using a microproces- 
sor, can take many forms and can be viewed at many different stages of development For instance, debugging 
::of suctva microprocessor system occurs prior to executing BIOS (before the system is bootable), during BIOS 
power on self test (but with no operating system loaded), after the operating system is loaded (but with no ap- 
plication software loaded), and after application software is loaded. (BIOS refers to the Basic Input Output 
System of a microprocessor system.) Debugging and testing of the integrated processor is desirable at all of 
these stages. 
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on the same microprocessor system 

~*5^rf^ ^ system is in bootable .^condition 



^^Jsj"^ t0 system crashes and.hin- _ 



... "IJ„ „ ~ " '^^ejr^fietfebQ process.^ 

^.w^-...*.*. ^ of an j nte g ratec j micropro- 

yari^qp^tingj^ ^~:^?^?~r- r . ... 

OTIS StaaeST Or miCTOnrQCfiSSOr R V«f eiTTTtovotWr^tf rtK-f K^f ' leTTrrfm* hrTWt^frt ■ « rhlfi^flminY Af€ 




girtff gsoKfidif krt^rat^proee ssoi s - whi ch db^rrotTCqperi^^ 
connector or test rigjor each integratedjprocessor designed. _ . _ -^i^ - + - .--r- - - 



_ ^ |n accordance with one embodiment of the present invention, a microprocessor with built-in testing capa- 
|ll§Sl^^ the disclosed microprocessor includes a semiconductor die and a central 



and coupled to the central processing unit. The ^microprocessor further includes at least one functional unit 



25 



local.bus.-The testing circuit-initiates a bus cycle for testing purposes in response to atest command originating-—- 
external to the microprocessor. 



BRIEF DESCRIPTION OF THE DRAWINGS -^- 



. The features of the invention believed to be novel are specifically set forth in the appended claims. How- 

. FIG- t js a block diagram of an integrated microprocessor including a hardware/software debugging tool. 
.... .-.FIG. 2 is a block diagram of a targetxomputer system employina the integrated-microprocessorjalFIG. A 
_shown together with. a host computer. .,., ^ .. TWV . ^ ^^..^..^j.. . ; 



aggaass 





FIG. 9A-9B are flowcharts which together depict the operational flow of the debugging tool of trie present"""" '** 

*s FIG. 10 is a representation of the pin-out of the debugging tool of the invention. 

FIG. 11 A is a timing diagram depicting a memory read cycle in normal mode. 
" " FIG. 11 B is a timing diagram depicting an I/O read cycle in normal mode. 

^^^^:^^ZZ^ r :.^^^iFiG^^C Is: a timing" diagram depicting* ^memory wnte~cyde1n 'n^ " . " -•' 

t ~ TK3r^1I>is-£Ffirm :r "" • * • - . 
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FIG. 11 E is a timing diagram depicting a memory write cycle in system management mode (SMM). 



I. Operational Environment 
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^^ ^^^:S}^3J?}? c ^J?3 rz ^ of an Jntegrated microprocessor 10 in which the hardw are/softw are debug ging 
~~ tool (HDT)'1 5 of ffi'e'preserif w proc- * 

^-essingunit(ePU)20 which is sjtuatedonjemlconductor die 25. -Theterm "standalone" is used here to indicate 
. Ifiat the layoutTrbm'a standalone CPU such as/an Advanced; Micro Devices, Inc. Am386 or Am486 micropro- 
cessor, forexample, is fabricated on semiconductor die 25. Whereas such microprocessor devices are normally 
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used in standalone fashion surrounded by various support chips, in the present invention the layout from such 
a standalone microprocessor is incorporated on die 25 along with HDT 15 and other structures. 

_^.^s.seenjn H&J^ j^|Qcal-JzM^3Q..couples.CPU 20 to HDT 15. Other functional units which normally reside 
in standalone chips separate from the CPU, such as memory <»ntrpl!er_35,_direct memory access (DMA) con- 

3s£Sftl^ bus -3fr6n '}$&£$^f$cxft' 



bus port 30A is provided for interfacing external devices to local bus 30. 
" ~~ r An "expansion bus port 50A is provided to bus interface unit 50 for connecting external input/output (I/O) 
devices to microprocessor 10 via an expansion I/O bus 55. In one embodiment expansion bus 55 is a PCI 
(Peripheral Component Interconnect) bus as set forth in the PCI Special Interest Group specification for that 

Architecture (ISA) bus, an Extended Industry 
^^^^^^3^^^^f^^^^^^^Z^' { 9^ Channel bus (Micro Channel is a trademark of the IBM Corporation) 
'■"■' J> *^*%^ 6f_ this document, a peripheral device is defined as a functional unit which is 

located external to the microprocessor. 

A memory port 35A is provided to memory controller 35 to permit memory such as dynamic random access 
ffi ^memory (DRAM) or erasable programrnabte read-only memory^(EPROM) to be coupled to memory controller 
35. As indicated by the fungtlgnaj unit des ignated "other functional unit" 60, other functional units not listed 
a&ove'^ be coupled to local bus 30. 

As seen in FiGI;1£HE^ interface (or JTAG port) 15Afor coupling HDT 15 to a host 

unit 200 over a JTAG bus. The JTAG interface is defined by IEEE Standard 1149.1. 

In actual practice as shown in FIG. 2, microprocessor 10 is situated on a motherboard 100 which is also 
referred toas target system 100. Target system 100 communicates with a host system 200 during system test- 
ing. Target system 100 includes a disk controller 105 and a video controller 110 coupled to local bus 30 via 
local bus port-30A-A modern^ 15 and a keyboard or other input device 120 are coupled to I/O port 50A via I/O 
expansion bus 55. Arandom access memory 125, such as a DRAM memory for example, is coupled to memory 
controller port 35A as shown. 

Target system 1 00 is the system for which testing and debugging is desired at the multiple stages of system 
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test commands can be sent from host 200 to the integrated processor 1 0 of target system 1 00 to exercise and 



^m^tisTtf^^ 

" ' — 1 j —~ — Eiassa — • E — 



^rre~ero^f^ 

onto which debugging software can be loaded. It should be noted that the target system 1 00 under test is sep- 
arate and distinct from the host system 200 which will initiate and control the testing of target system 100. 



r A-simplified bk>ek-diagram-of HOT-45-rs -shown- in FIG; 3. In-RG. :3rfcus widths are-indicated by a hash 



jgS^a^ the^hasfr mark as per 

^^^^^ JTAG port 

r ^ OT£ ^*^fffT^ ihputlhrough which information (including commands, 



.;^^^^^^^^^2^S^tft^r^sTri3"data) are sent to HDT 15 from host system 200. The TMS input is a control input which informs 
;^^^^^S£^^^^qj. 1 5 how to interpret data input as per the IEEE Standard Test Access Port (TAP) and Boundary-Scan Ar- 
ciiitecture, IEEE Std. 1149.1-1990, which is incorporated herein by reference. The TCK input of HDT 15 is the 
JTAG clock input through which a clocking signal is provided to HDT 15 by host system 200. The TDO output 
45 of HDT 1 5 is the JTAG data output through which responsive test data, results and status information are sent 
from HDT 15 back to host system 200. The protocol of the signals on the TDI, TMS, TCK and TDO lines are 
all defined in the above-cited IEEE 1149.1 standard. 

The TDI and TCK inputs of HDT 1 5 are coupled to the input of a shift register 300 which includes an OP- 
CODE portion 305, a BE/MD portion 307 and an ADDR/DATA portion 310. In one embodiment of the invention, 
50 -shift register 300 is 50 bits wide to accommodate a 50 bit wide command from host 200. This bit width is al- 
located as follows: 4 bits to the opcode, 6 bits to the BE/MD information, 32 bits to the address or data, and 
8 bits to guard bits for the command. 

Shift register 300 is a serial in/parallel out - parallel in/serial out shift register. When a command is shifted 
into shift register 300 serially from the JTAG TDI data input line, the opcode portion of the command resides 
55 in the opcode portion 305 of register 300. The opcode is provided to timing and control circuit 355 via a 4 bit 
wide parallel output of opcode portion 305 as shown. Control circuit 355 causes the appropriate bus cycle sig- 
nals to be generated on local bus 30 so that the particular operation specified in the command's opcode is 
performed. More specifically, control circuit 355 issues the appropriate control signals on local control bus 360 
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■•■-:~:Which,& a^seen in FIG. 3. In this manner, the specified bus cycle is generated. 

j^-, j add^ss or datairlform^ command is forwarded from AD DR/DATA portion 310 to address 



^bua£4QTan^ out and trie-result is-.returned over - 

"^Ji:^ 310 Ls forwarded back to host 

_ ~ " ^ defines the task to be performed by HDT 

. ~ - , ■ - - ~ "S.^'J^'?]^^^^i\ ^!^T&0i&jte^ HDT 1 15 at which results or responses to the com- 

_ v ^ ' 'I-r." ~mandVare sent via JtAG bus 205 backliTthe host 200. the BE/MD portion 307 serves as a placeholder for 




325 as shown in. FIG..3. the output of data-out register 31 5 is coupled to a data bus 330 (D31 :D0) within local 
bus 30. The ?utpujLJ|^^ system control bus 22 which communicates system 
20 control infonnatfortSi^ ^ ^ \ _ 
bus-340 within Joc^rlis;?'^^ 



HDT 15 includes a "data-in" register 345 which is coupled between the data bus 330 ofjocal bus 30 and ;: __ 

"* " ^ 

bus in-response to commands and-provides that result data to multiplexer 350r The second input of multiplexer 

25 350 is coupled to the system control bus 22. More specifically, the output of control register 320 is coupled to 
the second input of multiplexer 350 such that the control bits stored in control register are provided to multi- 



..output of MUX 350 is coupled to the ADD R/DATA portion _310 of shift register 300. The informationjstored in 



L£While; many different to cau^ctifferent- ^ 

system level functions- to be performed, such as.writing;and reading particular menwyiocations^a,^ 



~ 1' 'S-shifted^flto^shiffcr^^ signal TCK. 

of j npu t jp. 



1149.1-1990. More par- 

^j^^m^^ state machine which responds to changes jathe IMS and 



^CrTsfgnafs^^ 

which is decoded by TAP controller 352 to control test operations. The state diagram for TAP controller 352 
as per IEEE Std. 1149.1 is shown in FIG. 4. In FIG. 4, the value shown next to each state transition represents 
45 the signal present at the TMS pin at the time of a rising edge of clock TCK. More information with respect to 
TAP controller 352 is found in Chapter 5 of IEEE Std. 1149.1. The state diagram shown shown in FIG. 4 is also 
" ' ■ referred to as the JTAG state machine. 

_Wh£TVthe. opcode. rjQrtpn^aJid : address .p.Qrtioa of .the. cqmman&icaate„with the BE/MD portion, have 
* been fully clocked into shift register 300, aXoad Shift Register signal is generated and the opcode portion or 
so opcode of the command is provided to timing and control circuit 355. Data, namely commands, are written from 
host 200 to HDT 1 5 while HDT 15 is in an °Update-DR" state under the control of TAP controller 352, and return 
data are written back to host 200 in a "Capture DR" state both under the control of TAP controller 352 as per 
the cited IEEE Std. 1149.1-1990 specification and as seen in the state diagram of FIG.4. Read data are cap- 

tured during the "Capture DR" state and shifted out during the "Shift-PR" state. Write data are shifted in during 

55^fi^rTifro 

' As shown* in FIGr5,controI circujt 355 IncTiHes^^ decodes the particular op- 

. - » .. code (in this example, a read.opcodej provided- by opcode portion 305. The LbAbSHIFfJrREGISTER signal 

from TAP controller 352 informs opcode decoder357 of the fact that a new command including opcode, BE/MD 
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and ADDR7DATA portions has been fully shifted into shift register 300 and is ready for processing. 

Opcode decoder 357 is coupled to shift register opcode portion 305 (see FIG. 3) to receive the opcode of 

:-.^_each command senUaHDTAS.frpm host 200- vialhe JTAG bus 205. Each command includes an opcode field, 

^ M : t ._ a^BE/MD field and an ADDR/DATA field. Op^^ decoder 357 decodes the particular opcode (opcode field) 

assigns values to the Bus Cycle Type signal according to the particular type of opcode loaded in shift register 
300. In one embodiment, type bus 353 is 3 bits wide and is capable of specifying 8 different types of com- 
mands. 

In one example, if the opcode corresponding to a read memory bus cycle is received by opcode decoder 
glpslpg||§3^|g|^^ cycle type input of bus cycle state machine 

^^^^^^^^^^^^^S^^^^^^§M^19. read b ^s cycle is received by opcode decoder 357, then decoder 
" ~ ; ^ ^ 358. 

-Several-typical commands which are transmitted to HDT 15 for decoding and processing are listed below 
in TABLE 1. The following commands correspond to the different types of bus cycles or activities which can 
; %e«latetf fbMestta^^ invention. These commands are alternatively 

referred to as built-in commands. 



TABLE 1 
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BUILT-IN COMMANDS 



Command Format 



00 00000000 [Null]" 
00 1000 0000 [Null] 
00 11 00 0000 [Null] 



10 Q0MD--BE- [Addr] 
10 01 MD -BE- [Addr] 




Command Name 



No Operation (NOP) 
Select Control Register 
Select Data Register 



Generate Interrupt Acknowledge Cycle 
Generate Special Cycle 

Generate I/O Write Cycle * 



Sm&tet&Wemofy Code* Read Cycle 

^\&^^SS^^cm^^. if***!, i 

Generate Memory Data Read Cycle 
Generate Memory Data Write Cycle 



The Byte Enable (BE) field of the command format indicates the particular bytes to be written or read for the 
45 particular accessed word. On writes, the selected bytes are written. On reads, the memory controller ignores 
the byte enable and reads ail bytes of the word. An example of a special cycle listed in Table 1 is the conventional 
halt cycle. The byte enables and address (A1.A0) contain one of the legal combinations in Table 2 below; In 
Table 2, A1 and AO are the two lowest order bits of the address referenced in the read or write. 
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*■*■;* " Table 2 

■d^HRStim^ (BEHELD .QEIHE.BUILT^1N;C0MMAND:=::=*= 





1011 

0011 

btit 



One' byte at address 00 
Two bytes ataddress 00 

One byte*at aldre&'Of "* 



^-H'Twcrbytes atatfdress 01^^-^^' 
^hreerbytes^-acWrBsaU^—"^^ 
One byte at address 10 
16:, ^^^^^^^S^^S 



"c5SB^y^at'a3I^^TI 
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On special bus.cycles, thejsyte enables (BE's)jdentify.thetype^tcydeb^ 

Table 3 




1101 



Cache Flush 



■btal.fcr, 



Data (15:08) 




for a particular memory read 

■** sa - care.) More particularly, 
_^&J^iy^ld_^c^ normal memory, system management mode 

Table 4 



45 
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..50.;, 



MODE (MD) FIELD OF THE BUILT-IN COMMAND 



01: - 

10 
11 



Addcess Space- 



_ _ f?.*^K^^:i2r£^ 

System Management Mode (SMM) 

System Debug Mode 

Illegal 



'5*5 



. , It is noted that the commands of Table 1 are "built-in commands" in.tb.at they^are.hard-coded.into state 
--.^machine 358.- These commands-can advantageously be executed without the involvement of the CPU^jn^other 
"Wbrds7bus"cycles*a"nd I/O activities can be performed without CPU jnvolyement More particularly,* maiifmem-'' 
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ory reads and writes as well as I/O reads and writes are desirably performed for testing purposes without CPU 
involvement. For this reason, HDT 15 is particularly effective in debugging partially operational computer sys- 
r J$.™s or computer systems in the early stages of system development 

Inactual practice, a read local bus cycle is implemented in the following fashion. The read data local bus 

and processing by state machine 358 (FIG. 5). A Generate Memory Data Read Cycle command, namely 
1110MD-BE-[Addr] as set forth in Table 1, is first sent to HDT 15. This read command is shifted into register 
300. In so doing, the read opcode resides in opcode portion 305, the BE/MD information resides in BM/MD 
portion 307 and the specified address to be read resides in ADDR/DATA portion 310. 

decoded read opcode-information (bus 



^t^^^S^^^^^^^^^^^P^^P^^^S^^ clock pulse is issued to address register 325 to load the address 
C^™!^ f ™ m ADDR/DATA portion 310 into address register 325 . State machine 

— -358 generates standard local bus control signals to cause the specified local bus operation, here a memory 
read, to be performed. The data stored at the specified memory address then comes back over the data bus 
^^s*5s^33eM(^^ pulse is issued to data-in register 345 

to cause the return data to be loaded into data-in register 345. 

To Vec^pff decoded, state machine 358 generates the cor- 

responding appropriate local bus signals for carrying out that specified type of local bus cycle as set forth in 
the Am486 DX/DX2 Microprocessor Hardware Reference Manual published by Advanced Micro Devices, Rev. 
1 , 1993, the disclosure of which is incorporated herein by reference. More particularly, bus cycle state machine 
358 of FIG. 5 generates the appropriate standard local bus control signals as follows: ADS#, EADS#, M/IO#, 
D/C#, W/R#, BLAST#, RDY#, BRDY# to initiate a read as per the above manual. 

It is noted that irrone embodiment of the invention, when memory reads are performed, all four bytes which 

are specifiable by the byte enables (BE0-BE3 of the BE/MD field of the command), are received whether spe- 
cified or not by the byte enables. However, when memory writes are performed, the particular byte or bytes 
specified by the BE/MD field are written. 

_ To complete the memory read, host ^^O^ends HDT 15 a second command^namely a SelectData Register 
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MUX 350 to use data-in register 345 as its input. The output of MUX 350 is coupled to the input of ADDR/DATA 
to-ArofeET^^rtidn 

TDI, the return data in ADDR/DATA portion 310 is serially shifted out of register 300 to the TDO output 15A. 
The return data is then communicated over JTAG bus 205 back to host 200. It is noted that if a series of read 
commands are going to be strung together, then the next read command in the series will cause the return 




input of bus cycle state machine 
to state machine 358. In this manner, state 
ea decoded opcode has been transmitted to the Bus Cycle Type input 
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S^^5fcra^^^i^^|ffTs-i^w time for the state machine to generate the requested bus cycle, 
vvnin^fne^ertet^orr ofareaa memory local bus cycle has been discussed above, many other different 
types of bus cycles can be performed using the described testing technique. Reads/writes (R/W) to memory, 
R/W to peripherals (I/O devices), and also R/W to devices on a PCI expansion bus 55, interrupt acknowledge, 
the special bus cycles in Table 3 and other bus cycles can be performed. It is noted that these bus cycles can 
be performed when the system is in either NORMAL or DEBUG mode. When HDT 15 is initiating bus cycles 
for testing purposes, HDT 1 5 is said be operating in a bus cycle mode which may be a part of either NORMAL 
or DEBUG mode operations. 

The generation of a write memory local bus cycle is now discussed for example purposes. To initiate a 
write memory cycle, host 200 first sends a Write Data Register command (see Table 1) to HDT 1 5. Once this 
write command is shifted into shift register 300, the opcode resides in opcode portion 305 and the data resides 
in ADDR/DATA portion 310. The write opcode within the command is decoded by opcode decoder 357 and 
write data register type information is sent to state machine 358. The Write Data Register command requires 
no action by state machine 358 in terms of generation of local bus signals. State machine 358 waits for further 
instruction. A data-out clock signal is issued which causes the data in ADDR/DATA portion 310 to be loaded 
into data-out register 315. 

Asecond command is then sent by HDT 15 to complete the desired memory write operation. More partic- 
ularly, a Generate Memory Data Write command (see Table 1) is sent to HDT 1 5. This write command includes 
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both a memory data write opcode as well as the address to which the already loaded data is to be written. The 
memory date write opcode is provided to opcode decoder 357 which decodes the opcode and provides memory 
--.Jtetaw^ by timing and control 

^ircujtJjS tQjoad tta register, 325-State ... 

-bus cycte to-fae perfornterf on local" bus ; 307 When the local, buscycle is completed, the data stored in data-out 
register 31 5 is stored in memory at the address contained in address register 325. 

It is noted that opcode decoder 357 generates the following.clocksignals: data-in clock, data-out clock, 

;^c^^ctocfc^^ respictiveiy^su^ 

*-ift#ede^ighBl?is^ 




?a£j^^ pulsejs aenerlfejd^ 



far 

---r^&Qte^^ contents of ADDR/DATA portion 310 of shift reg- 

r^l5lB e S! 5^L^5^ r BS5 ^ . J 1 -^ add res . L^5P*S, ii9 n ^ P u * se is generated when opcode decoder jdeqodes one^of 
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10 10MD -BE-[Addr] 
4CLUMD-BE- [Addr] 



11 00MD -BE-[Addr] 
^aiMa ? B£-tAddrl; 



11 10MD -BE- [Addr] 



Table 1A 



Generate I/O ReadCyda^^^.,- : 7 
^enerate^HO^ri^ 
Generate Memory Code Read Cycle 



Generate Memory Data Read Cycle 



Bus cycle state machine 358 of contrdi circuit 355 generates bus transactions on local bus 30 as requested 




' ~. L.„lype.aignaC^^ processor 10. 

„ •— '^~ ^;1p Mdijion jpjespoqd^ in the generation of the local 

w^bwcytf^ listed below in Table 
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Table 5 

HDT CONTROL COMMANDS (CONTROL REGISTER 320 PINOUT) 



Syste m Co ntrol Bus 22 Bit(s \ 



Name — , 



CPUCYC 
STOPCPU 
RESET,- ^ 
RESCPU 
ENAPCI 



DSPCYC 

FLUSH 
DISABLE 
DBGINTR 
HDTENA 



Oescriptioa.(Command Function). 



Execute a CPU single step 
Stop the CPU 
Reset the System 
Reset the CPU 

Enable PCI access to internal registers (aka. PCIJOEN) 

-Display all cycles on the PCI bus (Expansion Bus 55 is 
a PCI bus in one embodiment.) (aka. BIU_PASS) 

Flush the CPU cache (aka. FLUSH#) 

Disable the CPU cache (aka. KEN# to CPU) 

Generate a DEBUG INTERRUPT (aka. DBGI# to CPU) 

Enable all Hardware Debug Functions 



25 



The HDT control commands are carried out by raising selected bit positions within address/data portion 310 
to a high state. The bit position within address/data portion 310 which is thus raised high causes a respective 
bit position within control register to change state. This change of state of a bit position within control register 

~ desired* command function. r 



^r^r^or- ; exam pt^shoutd^the us^of^ ^s ystem^desire to Reset The System, :'"thgjuser Instructs host 200 to 

^^omm^ Register command. The RESET 

command is transmitted over JTAG bus 205 as a bit pattern included within the Write Control Register com- 
mand wherein position 7 of the address/data portion is high. The bit pattern of the command is shifted into 



jcbrngj.^^ bit pattern contained 



i^dtfe^ 22 such that a corresponding line 7 (RESET 



ion on system control bus 22 causes CPU 20, which is 




^^i^^^^^^p^^^S^^^^l^^^rjte f Control Register command including a bit pattern with pos- 
^^Sorfcf^ from host 200 to HDT 15. if a "generate a 



address/flat; 

debug interrupt command" is desired, then a Write Control Register command including a bit pattern with pos- 
ition 1 being high in the address/data portion thereof is transmitted to HDT 15, and so forth in a similar manner 
45 with the remaining commands of Table 5. 

In more detail, in the case where the test operator desires to flush the CPU cache (not shown separately, 
but included within CPU 20), a Write Control Register command with the HDTENA and FLUSH bits set (namely 
bits 0 and 3, respectively of the bit pattern) is sent from host 200 to HDT 15 over JTAG bus 205. In the case 
of such a cache FLUSH command, the command includes a set bit at position 0 which enables the HDT when 
so the corresponding line of system control bus 22 is caused to change state by control register 320. The command 
also includes a set bit at position 3 which initiates the cache flush when the corresponding line of system control 
bus 22 is caused to change state by control register 320. In the present example, the data portion of the com- 
mand includes a bit pattern wherein data bit 0 and 3 are set and the remaining data bits are not set. 
. When an HDT command such as the FLUSH command is transmitted within a Write Control Register com- 
55 maritfto shift register 300 of HDT 15, the opcode portion (Write Control Register) of the Write Control Register 
...command appears in opcode portion 305 of shift register 300. The data of the Write Control Register command, 
~ ^namely the HDT control command bit pattern which indicates the FLUSH, appears in data portion 310. Acontrol 
..^.register clock signal pulse is generated when the Write Control Register command is received and decoded 
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by HDT 15. The control register clock pulse causes the bit pattern in data portion 310 to be loaded into control 
register 320 and to be supplied to system control bus 22. A FLUSH of the CPU cache thus results when the 
,.^Jt pattern v of the HDT controLcommand is. impressed on,system-control bus 22 by control register 320. The 

similar manner. Whereas the built-in com- 

' v ^a^ ' ' . -• ;• ' - 

The manner in which a "snapshot" of selected signals on system control bus 22 is sent back to host 200 
is now discussed. The two input multiplexer 350 provides either return data/result information from data-in reg- 

the upper. 22 bits cleared to zero in the 



20 



350. to use thej^n (10) lines from control register 320 as its 7 
' tit "patter ^rifot^ue.toaded therein byThe-ia^Wfite 6ontrotRegistercommand. Each bit stored- in a bit 

* 300 transmits its address/data portion 310 contents (bits 0-31) back to host 200. As seenin FiG. 3, the ! DONE! r " ' ^ " 
HOLD, INTR, DBGI#, SMI# and INTR_MODE (2 lines) lines are coupled to opcode portion 305 and BE/MD 
portion 307. The signal lines are coupled to respective bit positions within shift register 300 according toTabla. 



.25 




-33,32 



45 



50 



SYSTEM "CONTROL STATUS 



Bit(s) 



36 
35 



0-31 



Name 



INTR 
DBGI# 



INTJt-l^ 




Description 



Maskable Interrupt Is Pending """'""j" -. 
Debug Interrupt Is Pending 



: T^^(^Memory Spare Used By Current Memory 
Cycle 



DATA or CONTROL REGISTER CON- 
TENTS " : 



01 System Management Mode 

1 0 System Debug Mode 

11 System Debug Mode entered from System 
Management Mode. 



Returned result data or control register status. 
(Right justified in 32-bit field. Unused bits are 
zero.) - • 



^-•^-vJQ/hen; the, next .command from host 200 is received by HDT 15, the contents stored in ADDR/DATA portion 
310 (whether it be returned data or control register contents) are shifted out to TDO and to host 200 via JTAG 
;; ,.bus 205. Together with the'set ADDR/DATA portion 310 contents, the contents of opcode portion 305 and BE/MD 
: ' 'portion 307-are shifted out to TDO'and To host 200 aswell. Irr this^manner. a snapshot of the current state of 
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the 6 system control signals DONE, HOLD, INTR, DBGI# P SMI# and INTR_MODE is provided to host 200 with 
each transmission of return data. 

Examining these 6 system control bus signals in this manner permits the test operator to determine if a 
system management interrupt is pending (see SMl# in the snapshot), to determine if an interrupt is pending 
^seelNTR in4he snapshot)£fadetennineHt^ orta determine the 



current state of the microprocessor, namely, normal or system management mode (see INTR_MODE in the 
snapshot). It is noted that the snapshot can also be examined to determine whether or not a debug interrupt 
is pending (see DBGI# in the snapshot). HDT 15 also drives the MEMJvlODE lines in system control bus 22 
to cause each memory cycle to be directed to the appropriate memory space, namely to normal memory space, 
.^t a-.i ... system management memory space or special debug memory space. In other words, the two dedicated MEM_MO- 
DE signal lines specify the operating mode of the current memory cycle. 

The symbol # in a particular signal indicates that the subject signal is active low. It is noted that 'Data" as 
set forth at the end of Table 5A refers to the 32 bits of data captured by HDT 1 5 from local bus 30 in the course 
of testing. 

— The - signal INTR_MODE refers to the current state in which processor or CPU 20 is operating. The 

INTR_MODE signal may assume four different states or modes, namely, Normal Mode, System Management 
Mode, System Debug Mode and System Debug Mode entered-from System Management Mode. Normal Mode 
is defined as the operating state for operating systems and software applications code. System Management 
Mode refers to the operating state provided in the Am486 microprocessor for power management code. System 
20 Debug Mode is the operating state for debug code employed in the present invention. 

_SMI# is the signal to the processor or CPU 20 from circuitry external to the processor (for example, an 
external power management controller) that indicates that a system management interrupt is requested. DBGI# 

- is the signal to the processor or CPU 20 from the HDT which indicates that a debug interrupt is requested. 

INTR is the standard interrupt request signal to the processor. HOLD is the hold request signal to the processor. 

25 The above-described system status signals of Table 5A are captured as a snapshot of the current state 
of the internal signals with the listed names. This "data" (return data or result information) is sent out through 
the TDO line as new JTAG data is sent into the TDI line to HDT .15 from host 200. It is again noted that the 

The state diagram for one state machine which may be employed as bus cycle state machine 358 is shown 

IDLE 

^ — ^^^tat§7^ T1 state and 

-v- : r - f >2: the T2 state; As.seen.in FIG. 6,.the state diagram includes four major sequences, namely generate a bus cycle, 
stop the CPU, single bus cycle step of the CPU and generate a bus cycle from a stopped CPU. 
. . Bus cycle state machine 358 is reset at power-on to the IDLE state. The state machine is also held in the IDLE 

-interfacerlfa^bus cycle request is detectedpstate machine 358 asserts bus request (the HDTJHOLD signal) 
.^.^.-^^r—^^ bus cycle state machine samples the bus grant 

ra?tWfgnal*"is received, state machine 358 takes control of local bus 




i uj ^ ...^-y-g^..^^, ^ .... e.Thle state machine transitions to the T1 state one cycle later and 

^^•S^ is act"a"y performed in the T1 and T2 states. More 

particularly, in the T1 stateTaddress information is propagated to the device (or memory) upon which the re- 
quested bus cycle is to act. In the T2 state, data is propagated to or from the device (or memory) which was 
addressed in the T1 state. The bus cycle which is performed is a conventional bus cycle as described in the 
45 Am486 DX/DX2 Microprocessor Hardware Reference Manual published by Advanced Micro Devices, Rev. 1, 
1993, for example in Chapter 7 thereof. More information with respect to the standard T1 and T2 states is pro- 
vided in this Am486 Reference Manual. When the bus cycle is completed as indicated by the RDY or BRDY, 
, ^ " / J ^ll^gndjjl^ to the IDLE state. 



A STOP command causes state machine 358 to stop CPU execution. This is achieved by requesting local 
50 bus 30. When this occurs, CPU bus cycles stop immediately and internal CPU activity stops as soon as the 
CPU requires external data to continue. As seen in FIG. 6, in response to the STOP CPU command the state 
machine asserts the bus request (HDT_HOLD) signal and transitions to the HOLD2 state. The state machine 
waits in the HOLD2 state until bus grant (HDT_HLDA) is detected and then transitions into the HLDA state. 
The state machine can remain in this HLDA state indefinitely during a debug session. While in this state, state 
55 machine 358 can perform bus cycles, allow the CPU to perform single bus cycles, or issue control commands. 
When the STOP CPU request is eventually removed, the state machine will return to the IDLE state. 

Bus cycles are initiated from the HLDA state as just described. As seen in the state diagram of FIG. 6, in 
response to a bus cycle request, the state machine transitions to the HOLD1 state and then to the T1 and T2 
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states where the requested bus cycle is performed. The state machine then proceeds back to the HLDA state 
after performance of the requested bus cycle. In this instance, the state machine does not need to acquire 
JocaLbus.30 before the cycle and does not release bus 30 after the cy.de-.r~r.---.-. . . -~: - 
-.. .^.CPU 20 is permitted to singlg jjtepjbyjretummg con 30 to CPU 20 for one clock cycle. In response 

' "r-equesfs maybe In ff!e systlfi^ af thT^^ monitors the CPU_HOLD signal (or ail of the system 

requests) and waits until CPU JHOLD goes away for one clock cycle. The state machine then asserts HDT.HOLD 
and transitions into the HOLD2 state. The state machine then waits in the HOLD2 state until HDT_HLDAis detected 
, and then.returnstothe- HLDA state. ^ r "^~-^^^ - ^ - -. w^*- - 

menVfnain memory space spans from zero to 4 Gigabytes. Two reserved memory areas are indicated in FIG. 

^,^^^»^^^ 

..w.-^ ^~-^^of^moi^2£i&^ Whereas prior microprocessor memory systems employ 

^ _a. re?^^^M^^^^^stems management purposes, such as-power.saving.for example^the present in- 

f^^vi^nSfP^ 

__„a£?3 .365 ]?Jf5Pi9y£dJi^^9ie_debyg software. In this particular embodiment, both the debug, memory area 

^_J„365 Jar^f^ 64Kreserv^3ri^ 

be employed asweil.-- -..1 . "11 r^^C^^"^^ T '"^J^S'S-" 

It is noted that microprocessor 1 0 includes a conventional arbitration circuit or arbiter 400 as shown in FIG. 
20 8 for determining which particular functional unit is granted access to local bus 30 at any particular time. FIG. 

HDT 15, DMA 40, BIU 50 and CPU 20 all contend for local bus 30. When HDT 15 desires access to local bus 
30 as a bus master for that bus, HDT 15 sends an HDT_HOLD signal to arbiter 400. If arbiter 400 determines 
that CPLb20;:BMA4G and BIl^5&^ 

an-HDTJHLDAsignal(bolda(AnowIedge):signaI-to:HDT15atto current local bus cycle. In a similar 

manner, CPU 20, DMA 40 and BIU 50 request access to local bus 30 by sending CPU_HOLD, DMA_HOLD 
an^lU^ respectively, taarbiter 400. Arbiter 40Q g^ts access to 

units. Thus, when state machine 358 asserts HDTJHOLD to arbiter 400, an HDT JHLDA hold acknowledg e sig- 

— . : iv W/R#„BLAST#„ ADS#, MEM^MQDE;.ADDR and.BE# oalocatxontroi bus 360 of local, bus 30. The particular 

; bus transaction (memory read, memory write, I/O read, I/O write, for example) specified by state machine 358 
— -~-r --- r.-_i. „ v _ ji^^r^d jMJt. The_functional units of integrated processor 10 respond to the assertion of the above signals 

bus -transaction; — — — , — , 

— , - ^fi6:~Wtier^ state awaiting a new 

^ ' ^^ * c " fW *~ a ^^ other words, 

200 for de- 



,-~25 ... 



In arbitration, whichevermaster initiates a transaction waits for a ready signal from the functional unit 
it is seeking to communicate with. For example, when HDT 15 is attempting to perform a memory read and 
memory controller 35 is ready with the requested data, memory controller 35 sends a RDY# or BRDY# to HDT 
45 15. HDT 15 then picks up the requested data which is available of local bus 30. 



IV. Hardware/Software Test Tool - Detailed Operation DEBUG MODE 



50 



55 



Intone embodiments 'the - invention, ~CPIT20 executes debugging Software '"wfife ' 
memory area 365. For example, a commercially available debugger program such as Turbo Debug from Bor- 
land, Inc. may be employed. More particularly, the debug kernel from such program is stored in debug memory 
area 365 and the user interface portion of the program is stored in host 200. When this debug software in mem- 
ory area 365 is being executed, the system is said to be in debug mode. The debugging software is used for 
debugging applicatior^whichjrun on tjhetarget, and can also be used in low level (early development stage) 
"memo^ 

Once HDT 15 causes CPU 20 to enter debug mode, the CPU is capable: of interpreting debug commands. 
In other words when HDT 15 enters this command Interpreting debug mode, the CPU can execute the debug 
commands featured by the particular debugger program;- For example, when the Turbo Debug kernel is em- 
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ployed in debug memory area 365 as the debugger program, the CPU can respond to the following debug com- 
mands of Table 6: 

Table 6 



DEBUG COMMANDS 

- read and write a CPU internal register; 

- single step through a program; 

- prepare to execute a program; 

- standard commands; 

- other debugger-specific commands. 



20 



25 



These sample debug commands are given by way of example and not by way of limitation. Other debug com- 
mands in addition to those listed above may also be employed. 

Initially, the entire debug software program including both the debug kernel and the user interface portion 
is stored in host 200 in a non-volatile storage media. Each time target system 100 is turned on and host system 
^ 200 is booM up, the debug kernel is transmitted or downloaded from host 200 over JTAG bus 205 to target 
^100^^ debug memory area 365. The debug 

kernel which is downloaded into debug memory area 365 includes a command decode and execute section, 
a debug interrupt handier and a breakpoint handler. In this particular embodiment the entry point for the debug 
kernel in memory 365 is O00FFFO. Once loaded in memory area 365, the debug kernel establishes a commu- 
nications protocol with the host from which it is then capable of receiving debug commands from the debug 
user interface portion on the host. The host communicates with the target system's debug kernel by using ar- 
bitrarily .ch(gen._ b ut s locations in debug memory area 365. The host wri tes com mand infor- 



memory area. The host then obtains the result or responsive information from the debug kernel by reading 

~ so.—f ^ ihejfefr^^ JTAG 



bus 205TTH e^ibbVe arrangement of debug 'memory "space 365 permit's host 200 to send commands to HDT 
"15 and receive results from HDT 15 without being intrusive on normal microprocessor operations since both 
the commands and results are stored outside of normal main memory space. 

When CPU 20 is executing debug code in debug memory area 365, it is said to be in the debug mode. In 



;r WRenrthe CFUencounters ohe'of theWe^con^ enter debug mode^ it saves the 

contents~of the CPU registers to main memory 125 for later recall. The CPU then looks to the debug memory 
|||||^^ namely the debug kernel. When the debug kernel is 



^^^ffijgp^ processor (CPU) registers 2) cause the CPU to resume 

I^ppI^^ application that is presently being executed 
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by the CPU and which is being debugged, and 4>perform single stepping through such software applications. 
These functions are available in the debug kernel. Results from these operations, if any, are stored in the de- 
bug memory segment 365 for later retrieval by host 200. 

The first way for the CPU to enter the debug mode is for HDT 15 to receive a specific command from host 
200 which instructs HDT 15 to generate a debug interrupt. More specifically, host 200 sends HDT 15 a Write 
Control Register command including a HDT control command (D8GINTR, see Table 5) which forces HDT 15 
and CPU 20 into the debug mode. A debug interrupt is thus said to be issued which causes the CPU to enter 
Jj?f .debug mo^ mode upon request as opposed to automatically 

upon encountering*a ^determined condition.'* 

A second way that debug mode can be entered is via address matching. As seen in FIG. 1 , CPU 20 includes 
four debug registers, namely registers DR1, DR2, DR3 and DR4. Selected addresses of interest to the test 
operator are stored in these debug registers. If the address of the current line of code which is presently being 
executed matches the contents of any of the four debug registers DR1, DR2, DR3 and DR4, then debug mode 
is entered by the CPU. 

A third way for CPU 20 to enter the debug mode is for CPU 20 to encounter a debug instruction in the 
course of normal execution of an application. For example, this would occur when a debug instruction is in- 
serted in an application program by debugger software such as Turbo Debug by Borland, Inc. Microprocessors 
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such as the Am486 are programmed to recognize the debug instruction and to enter a debug state when such 
an instruction is encountered. 

. As a prelude to discussing_the flow diagram of FIG. 9A-9B, it is noted that there are two ways for commands 
to fye _ ca rried out by JHDT 1 5. "Qjegeiwo wayscorrespond to the two different types of commands, namely debug 

commai^^s^^ 

'a'nd%:^^^^ 

With respect to debug commands which are carried out in debug mode, host 200 communicates with the 
target computer's debug kernel which is stored at a predetermined memory location in the debug memory seg- 
ment or debug memory space 365. The host writes a debug command via JTAG bus 205 to this debug memory 
^slfig^^ debug-space/it is.availabfer^ 

target CPU. The deBug kernel carries out the particular command and stores responsive information, namely 
~ *?!l e result,, in tha debugmenmry^ later retrieval by the.host computer. To retrieve this result information, 
— the host computer reads the result from the debug space via the JTAG bus. The host computer thus receives 
result information back frpnvthe debug kernel.. ...... . . . „ , 



in Tabhp 1 I , thes^c^mands can be carried out in either norma[mode or djebug mode. Likewise, the HDT control 
.. comman3$Jste4 5 can be carried out in either normakmqde or debu&moda^^ 

those times when target computer 1 00 is not in debug mode. Typically, normal mod^Tncludes those times when 
target computer 100 is executing an application program or is idle. 

20 

-r- V. Operational Flow- ^^r^^^~"7-"Pr-.-.-^- ~ i ,--^^ r „;_^.^^-_ rrr ^... 



FIG. 9A and FIG. 9B together form a flow diagram depicting the operational flow of the system which in- 

*^^cludes target-computer 100 and- host computer :200.. Fot:clarityr : FIG.- 9A is directechmainly^to HDT operations 

-25 . ..wherein HDT 15 receives; commands from the^host 200 and so-called "primitive" operations, such as reads 
and writes, are performed by the HDT on the local bus. FIG. 9B is directed mainly to those system operations 
wherein CPU 20 is called upon to execute the debug kernel which is stored in debug memory segment 365 



:onsv:suc 




_ 

"^WelhW^ isidle. An HDTR/W 

— command (read/write command), an HDT-control command or an HDT debug interrupt is issued or occurs at 

block 505. A test is then conducted at decision block 510 to determine if HDT 15 has issued an R/W command 
(read/write command) or an HDT control command. 

a bus cycle by issuing the appropriate bus cycle control signals on local control bus 360 to cause the local bus 
-transaction 514. A test is 

^^/^^^ available. 

When local bus 30 becomes available, then the specified bus cycle is performed as per block 520. A DONE- ... 
signal is then generated when the bus cycle has been performed to signify that the bus cycle is complete. If 
the specified local bus operation is one where data is returned, as for example in the case of a memory read, 
then such data is returned to host 200 over JTAG bus 205 in block 530. For this data return to occur, MUX 
350 is switched to couple data-in register 345 to the address/data portion 310 of shift register as per MUX select 
block 527. The system control status signals, DONE, HOLD, INTR, DBGl#, SMI# and INTR.MODE are re- 
turned as well to host 200 at block 535 along with the return data. Process flow then continues back to block 
500 with target 100 being in the normal mode. 

If a determination was made at decision block' 51 0 that an HDT control command is : present," then'as per ' 
block 540 the bit pattern of the HDT control command is loaded into control register 320 and is placed onto 
control bus 22 to initiate the function specified in the control command. The function specified in the control 
command is performed at block 545. A snapshot of the control register 320 lines is returned to host 200 at 
block 550. In more detail, when a Select Control Register command is received by HDT 15, the MUX select 
signal provided to MUX 350 causes the controj register 320 output to be coupled through to address/data por- 
tion 310 of shift register *30(f as "per MUX seiect biock'547. In this manner, the control register line snapshot 
is returned to host 200 ? at block 1550. Arthe~samejirhe'that the control register line snapshot is returned, the 
"system control status signals DONE,- HOLD JNTR, DBGI#. SMI# and INTR_MODE are returnee! as well to host 
200 at block 555. Process flow then continues back to block 500 with target 100 being in the normal mode. 



45 



so 



55 



-15 



EP 0 652 516 A1 



While not shown graphically in the flowchart of FIG. 9A, it is noted that whenever microprocessor 10 is in 
normal mode as in FIG. 9A, microprocessor -10 still continually checks to see if a debug interrupt condition 
exists as indicated in FIG. 9B. More particularly, the presence of four conditions is tested at decision blocks 
561. 562, 563 and 564. Decision block 561 checks to see if a debug interrupt command DBGI has been issued 
& . by hcst.20Qto microprocessor^Oi-Theissuancaof such a command will place microprocessor directly in debug 
~ mode. A test is also made at decision block 562 to determine if the instruction presently being executed is a 
breakpoint, and if so, microprocessor 10 enters debug mode. Moreover, a test is performed at decision block 
563 to determine if the address of the instruction currently being executed matches the contents of any one 
of the four debug registers DR1, DR2, DR3 and DR4. If such a match occurs, debug mode is entered. Another 
1Q-. -itest is conducted at decision.biock 564 to determine if the instruction currently being executed by the micro- 
processor is a debug instruction, and if so, debug mode is entered. 

More specifically, if any of tests 561-564 are answered in the affirmative, the processor saves the contents 
of its internal registers to main memory at block 565 and enters debug mode. The debug kernel which is stored 
in the special memory segment 365 is then entered and executed at block 570 as the processor enters debug 

A test is then conducted at decision block 575 to determine if a host debug command is available, in other 
words, HDT 15 looks to see if any Table 6 debug commands have been received from host 200. A floating 
block 580 is used to indicate that the processor is continually looking to see if HDT 15 has sent a command 
to debug memory space. Once a host command appears, the host command is performed or executed at block 
20 585 and simultaneously therewith the host ready status is prepared at block 590. That is, if host 200 is ready 
L^-r^-to sendianother command to HDT 157 it so indicates by sending an appropriate host ready status signal to HDT 



15 over JTAG bus 205. The next debug command is then sent to HDT 15 and is then performed by HDT 15. 
Results, if any, from CPU 20 and associated devices in response to debug commands are stored in debug 

memory segment 365 as per block 595, Host 200 retrieves these results using the JTAG bus 205. When host 

25 200 is done sending debug commands to HDT 15, host 200 sends an exit command to HDT 15. Atest is con- 
ducted at decision block 600 to determine if it is appropriate to exit the debug mode. If an exit command is not 
detected at decision block 600, then process flow continues back to the host command available block where 

then the internal registers of CPU 20 are restored at block 605 and process flow continues back to block 610 
-3<F*?l&:vfti[^ is S aid to be in debug mode 

: ^^^ffi^u^c5uTBtecks 570-605rWhen the processor re-enters the normal mode at block 610, the processor can 
be placed in system management mode (block 615) by issuing a system management interrupt thereto. Once 
back in normal mode, the processor continues to check for the presence of any R/W commands or HDT control 
commands (block 5 1 0) as in the flow diagram of FIG. 1 0A and also continues to check for the presence of any 
^ _ of the.;f our condition s'^ debug .models in the. flow diagram of FIG. 9B. 

~ *™ the leftmost path in the 

flow diagram of FIG. 9A are advantageously performed without CPU involvement This is especially beneficial 
il^e^earl^i^ computer 100 when all of the components of the target 

SSMTr^^htira'sr; the debug commands which are performed in the flow 
)B^t^^ particularly, debug commands are actually executed 

by CPU 20 and results are passed back to host computer 200 via the debug memory space 365. The built-in 
commands are used to pass the debug commands to the CPU. 




VI. Bus Structures And HDT Pinouts 

45 

Returning momentarily to the case where one of the built-in commands of Table 1 is being executed by 
HDT 1 5, it will be recalled that the bus cycle specified in the command is carried out and that a result is returned 
over local bus 30. In the case of a read, the data that is read from memory is returned as a result, In addition, 
a snapshot of local bus 30 is returned to host computer 20. This snapshot includes a JTAG Status Return which 

50 is defined as information with respect to the current state of the first six internal system control bus signals 
given above in Table 5A (ie. bits 32-38) and the contents of control register 320 (stored in shift register locations 
0-21 with unused locations being zeroed.) 

FIG. 10 is a diagram showing the pin-out of HDT 15 including the JTAG serial interface or port 15A, local 
bus interface 30A, the remaining pins of HDT 15 being the control interface thereof, namely system control 

55 bus 22. 

The pin-out of JTAG interface 15Ais conventional and is represented by the following pins of HDT 15 given 
in Table 8. 
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Table 8 
JTAG. INTERFACE 



CLOCKHDT 
CLOCKHDTF 

gbtiETHDT.^,^ 



UPDATEHDT 
HDTJDI 

HDT-TBO?^ 



:IN; - Clock Phase 1 
:IN; - Clock Phase 2 

:IN; - Copy shift register to destination 
:IN; - Input serial data 

^GW^^otpufcseriakdata^^ * — 



. The Cocai'Bus interface 30A is represented" by the following-pans^ 
^eariier^Jof^to 

30 includes the following lines listed in Table 9. It is noted that CPU 20 and HDT 15 each include pins having 
20 labels corresponding to the following lines of local bus 30 set forth in Table 9. 



Table 9 



25 



.k&YSCLKPZ-^ 
SYS_RESET 
A31:A0 
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LOCAL BUS PINOUT, 



Pin Name 



SYSCLK 



SYSCLKP1 



:IN; - Synchronous system reset 
:OUT; — Memory or I/O addresses 



BE3#:BE0# :OUT -- Byte enables 



Function 



; IN ; --Jyste mjd lock 



:IN; Clock phase 1 



D/C#~ 


-OUT -- Data (high) orCode (taw)"- — ™" — — 


W/R# 


:OUT Write (high) or Read (low) 


ADS# 


:OUT -- Address Strobe 


EADS# 


.OUT Cache Invalidate Address Strobe 


BU\ST# 


:OUT Last cycle of burst (low). 


RDY# 


:IN - Responder Ready, Single Cycle 


BRDY# 


:IN — Responder Ready, Burst Cycle 


KEN# 


:OUT- CPU Cache Enable 


FLUSH# 


:OUT Flush CPU Cache 



The pins and lines listed above for local bus 30 from A31:A0 through FLUSH# are standard to the Am486 mi- 
croprocessor which is manufactured by Advanced Micro-Devices, Inc. and described in the Am486 DX/DX2 
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Microprocessor Hardware Reference Manual, Rev. 1, 1993 published by Advanced Micro Devices, Inc. The 
signals SYSCLK, SYSCLK1 and SYSCLK2 are clocking signals which are supplied to HDT 15 to provide clock- 
ing to the components thereof. 

System control bus 22 couples CPU 20 to HDT 15 as set forth in the pinout listed in Table 10. It will be 
.recalled. that control register.320-drive&4hese€ystem control bus lines and that a snapshot of these lines with- 
out the MEM_MODE signal is provided bade to host 300 through the cooperation of MUX 350, address/data 
portion 310 of shift register 300 and JTAG bus 205. 



Table 10 





.-n-i— * - - - '"~* W SYSTEM CONTROL BUS 




Pin Name 


Function 


■ ■ 15 ~ 


HOLD 


:IN - System wide Hold Request 


INTR 


:IN - Interrupt Request 




DBGI# 


:OUT - DBI Request ~ 


20 


SMI# 


: SMI Request 


INTR_MODE 


:IN Operating Mode of the CPU (2 bit signal) 




MEM_MODE 


:IN - Operating Mode of the current memory cycle from CPU (2 bit signal) 


25 


BIU_PASS - 


:OUT- Instruct BIU to pass all cycles to the PCI bus (expansion bus) 


PCIJOEN 


:OUT - Instruct BIU to respond to I/O requests from external initiators 




SYJS^RESei.„ 






RESET 


:OUT - Reset CPU 



The following two signals relate to the control of local bus arbitration, but are grouped separately from system 
control bus 22. 





_ 35 






HDT_HOLD 


OUT- HDT Hold Request 












HDT Hold Acknowledge ™ 



JUs.note^ 20 and HDT 15 each includes pins having labels corresponding to the following control 



rrnest^effaDdve in Table 10 for system control bus 22 are standard to the Am486 micropro- 
cessor which is manufactured by Advanced Micro Devices, Inc.(AMD) and which is described in the AMD pub- 
lication Am486 DX/DX2 Microprocessor Hardware Reference Manual, Rev. 1, 1993. 

FIG. 11A-11E shows a series of timing diagrams illustrating the signals on local bus 30 while HDT 15 is 
being operated. More particularly, FIG. 11A shows local bus signals when HDT 15 is performing a memory 
45 read bus cycle in normal mode. FIG. 11 B shows local bus signals when HDT 15 is performing an I/O read bus 
cycle during normal mode. FIG. 11 C shows local bus signals when HDT 15 is performing a memory write bus 
cycle during normal mode. FIG. 11D shows local bus signals when HDT 15 is performing a memory write in 
system debug mode. FIG. 11 E show local bus signals when HDT 15 is performing a data write in SMM, system 
management mode. 

so While the above description sets forth an integrated processor apparatus with on-board testing capability, 

it is clear that a method of testing the integrated processor and associated devices is also disclosed. More par- 
ticularly, a method is provided for testing an integrated processor which includes a die on which a CPU and 
at least one functional unit are situated. The CPU and functional unit are coupled together by a local bus. The 
method includes the step of providing the processor with a testing circuit which is situated on the die and which 

55 is coupled to the local bus. The method aiso includes the step of sending a test command to the testing circuit 
from a host computer external to the integrated processor. The method further includes the step of receiving 
the test command by the testing circuit thus resulting in a received test command. The method still further in- 
cludes the step of generating a local bus cycle, by the testing circuit, in response to the received test command 
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to provide testing of the processor and devices coupled thereto. 

The foregoing has described an integrated microprocessor including a built-in testing capability. The inte- 
grated microprocessor test system is capable of testing the components of an integrated microprocessor and 
devices coupled thereto. Advantageousl^th^test system provides such testing throughout the multiple stages 
-^wfcrbpro^^ 

way through operating system load and application software development 

While only certain preferred features of the invention have been shown by way of illustration, many mod- 
ifications and changes will occur. It is, therefore, to be understood that the present claims are intended to cover 
all such modifications and changes which fail within the true spirit of the invention. 



Claims 



1.. An integrated microprocessor comprising: 
;c a - s^icoFducfordfe; ~ r ^ K -^" 7 ?^^* 
a central processing unit situated on said die; 



a.locai bus situated on~said die and coupled;.ta sa& 
at least one functional unit situated on said die and coupled to said local bus; and 
a testing circuit, situated on said die and coupled to said local bus, for initiating a local bus cycle for 
20 testing purposes in response to a test command originating external to said microprocessor. 

2, The integrated microprocessor of claim 1 wherein said testing circuit further includes decoding means 
for decoding a type of bus cycle set forth in said command. 

3. The integrated microprocessor of claim 2 wherein said testing circuit further includes a bus cycle state 
--^-machine for generating the type-of bus^cycie indicated by-said command. ~ - - - - 

25 4. An integrated microprocessor comprising: 
a semiconductor die; 

a central processing unit situated on said die; • 

^^If^S^^^dc^sl^g^nlt; ~ 



at least one functional unit situated on said die and coupled to said local bus; 

HsFmin 



,35... 



45 



50 



55 



rttpfe^ 

. . testing. means, situated on said die and coupled to said local bus, said testing means being operative 
in a bus cycle mode for initiating local bus cycles to test said microprocessor and functional units coupled there- 
to in response to_ test commands originating external to said microprocessor, said testing means being oper- 

; 3 tjye. !HJld^3L™^^ space. . 

5. 'The Integrated microprocessonsferaim 4 wHereivflaid festmg"mea^ 

for decoding a type of bus cycle set forth in said command. 

- 6.TheJrtiegratedjnicro^ 

7. The integrated microprocessor of claim 4 further comprising: 

at least one debug register situated in said central processing unit, 

said microprocessor including address matching means for determining when a match occurs between 
an address stored in said debug register and an address of an instruction which is currently being executed, 
said microprocessor entering said debug mode when said match occurs. 

8. The integrated microprocessor of claim 4 further comprising: 

debug instruction sensing means, situated in said central processing unit, for detecting when a currently 
executed Instruction is a debug instruction such that said microprocessor enters said debug mode when said 
debug instruction is detected. 

9. A computer development system comprising: 

a target computer including an integrated microprocessor having 
a semiconductor die; 

a central processing unit situated on said die; 

a local bus situated on said die and coupled to said central processing unit; 
at feast one functional unit situated on said die and coupled to said local bus, 
' a peripheral device coupled to said local bus; - *~ \ ' 'jJ.rL.v 

a memory coupled to said central processing unit and including a debug memory space for storing 
debug software; 
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testing means, situated on said die.and coupled to said local bus, said testing means being op- 
erative in a bus cycle modeior .generating local bus cycles in response to test commands originating external 
to said microprocessor, said testing means being operative in a debug mode for executing said debug software 
which is stored in said debug memory space, and 
5 a host computer, coupled to said target computer, for providing said testing means with test commands 

and for retrieving the results of said test commands from said target computer. 

10. The integrated microprocessor of claim 9 wherein said testing means further includes decoding means 
for decoding a type of bus cycle set forth in said command. 

11. The integrated microprocessor of claim 9 wherein said testing means includes debug mode command 
to-, ^detecting, means for. detecting -when said microprocessor receives a test command from said host computer 

including a debug mode request 

12 The integrated microprocessor of claim 9 further comprising: 
at least one debug register situated in said central processing unit, 

said microprocessor including address matching means for determining when a match occurs between 
is an address stored in said debug register and an address of an instruction which is currently being executed, 
said microprocessor entering said debug mode when said match occurs. 

13. The integrated microprocessor of claim 9 further comprising: 

debug instruction sensing means, situated in said central processing unit, for detecting when a currently 
executed instruction is a debug instruction such that said microprocessor enters said debug mode when said 
20 debug instruction is detected. 

14. The integrated microprocessor of claim 9 further comprising a test bus coupling said host computer to 
said testing means of said target computer. 

15. The integrated microprocessor of claim 14 wherein said test bus comprises a JTAG bus. 

16. A method of testing an integrated processor, said processor including a die on which a CPU and at 
25 least one functional unit are situated and coupled together by a local bus, said method comprising the steps 

of: 

providing said processor with a testing circuit coupled to said local bus and situated on said die; 
^ssss^efrdifTgF^ to said integrated proces- 

sor; 

—^receivrri^ resulting In a received test command, and "~ 

^^^lerTerating a [local bus cycle7bysaidt^ received test command to provide 

testing of said processor and devices coupled thereto. 

17. The method of claim 1 6 further comprising the step of. 
decoding the received test command to determine the particular type of local bus cycle specified by 

35 ^ said received test command. ^ ._ 

" - 18. The method of dlatm 16 wherein said functional unit isiTmemorycontroiler having a memory coupled 
thereto wherein 

— —^said^ending step includes sending a memory write request command to said testing circuit, and 

^^^^^^I^^^^^^SB^ra®^^^ fe P includes generating a memory write bus cycle to test said memory. 
SiF^^^^^Fne^ said functional unit is a memory controller having a memory coupled 

thereto wherein 

said sending step includes sending a memory read request command to said testing circuit, and 
said generating a local bus cycle step includes generating a memory read bus cycle to test said memory. 

20. The method of claim 1 6 wherein said functional unit is a bus interface unit having an I/O device coupled 
45 thereto wherein 

said sending step includes sending an I/O write request command to said testing circuit, and 

said generating a local bus cycle step includes generating an I/O write bus cycle to test said I/O device. 

21 . The method of claim 1 6 wherein said functional unit is a bus interface unit having an I/O device coupled 
thereto wherein 

50 said sending step includes sending an I/O read request command to said testing circuit, and 

said generating a local bus cycle step includes generating an I/O read bus cycle to test said I/O device. 

22. A method of testing an integrated processor, said processor including a die on which a CPU and at 
least one functional unit are situated and coupled together by a local bus, said method comprising the steps 
of. 

55 storing debug software in a debug memory space in a memory coupled to said processor 

providing said processor with a testing circuit coupled to said local bus and situated on said die; 
sending a test command to said testing circuit from a host computer external to said integrated proces- 
sor; 
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receiving said test command by said testing circuit thus resulting in a received test command, and 
generating a local bus cycle, by said testing circuit, in response to said received test commands to pro- 
vide testing of said processor and devices coupled thereto. 

23. The method of claim 22 further comprising the step of: . . _ 



'15 



to operate in a debug mode. 

24. The method of claim 23 including the step of detecting when said microprocessor receives a test com- 
mand from said host computer including a debug mode request thus causing said processor to enter said de- 
bug mode. 

said method-fur- 
ther comprising the step of determining when a match occurs between an address stored in said debug register 
and an address of an instruction which is currently being executed, said microprocessor entering said debug 
mode when said match occurs. 

26. The method of claim 23 including the step of detecting when a currently executed instruction is a debug 
instruction such that said microprocessor enters said debug mode when said debug instruction is detected. 
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